Gestión del cambio en proyectos tecnológicos

Gestión del cambio en proyectos tecnológicos

Seis claves para empoderar a la organización

Versión de libre distribución

Mar de núvols des de la Creu de Sant Miquel (Montserrat)

Primera edición en lengua castellana: Junio 2020

(c) 2020, Josep Lluís Monte Galiano

(c) 2017, fotografía de portada, Josep Lluís Monte Galiano. Mar de núvols des de la Creu de Sant Miquel

(c) 2018, fotografía autor contraportada, Gemma Saurina Rosell

www.calaixagil.com

ISBN-13: 9798710997949

Ninguna parte de esta publicación, incluyendo el diseño general y la cubierta, no puede ser copiada, reproducida, almacenada o transmitida de ninguna forma ni por medio alguno, tanto si es electrónico como químico, mecánico, óptico, de grabación, de fotocopia, o por cualquier otro método, sin autorización previa por escrito del titular del copyright.

Sobre el autor

Me apasiona la ingeniería de software. En especial las metodologías de gestión de proyectos y de ciclo de vida del desarrollo, y me gusta aplicarlas, practicarlas y fomentarlas. Intento crear entornos donde haya un equilibrio entre las acciones de contrato y de comunicación. Documentación efectiva por encima de documentación exhaustiva; y comunicación directa y acuerdos prácticos por encima de mails y reuniones extensivas.

La corriente Agile da respuesta a muchas de estas premisas. Pero hay muchos aspectos de las metodologías mal dichas anticuadas, como PRINCE2 o PMP, que encuentro imprescindibles y creo que pueden convivir perfectamente con Agile. Normas claras, delegación de responsabilidades, alcance y objetivos claros, son algunos ejemplos de buenas prácticas de métodos tradicionales con muchos años de experiencia.

Aparte de estudiar e implantar metodologías, obviamente las practico en los proyectos que me son confiados como gestor de proyecto, scrum master, product owner o como sea útil. En todos estos proyectos, independientemente del statu quo de la organización, intento aplicar una visión expansiva y participativa de la gestión de proyectos.

PRINCE2 Practicioner certified por APM Group. Profesional Scrum Master por Scrum.org y Product Owner certified por Scrum.org. Consultor informático desde hace más de 20 años en dirección de proyectos de construcción de software, implantación, PMO e implantación de estrategias de gestión TIC en organizaciones.

Master en Educación y TIC (eLearning) por la Universidad Oberta de Catalunya (UOC). Ingeniero Superior en Informática por la Universidad Oberta de Catalunya (UOC). Durante unos años fui colaborador docente del Master en Educación y TIC (eLearning), en las especialidades de Diseño tecnopedagógico y Trabajo Final de Máster (TFM) por la UOC.

https://es.linkedin.com/in/jlmoga/es

www.calaixagil.com

moga@calaixagil.com

Índice

Introducción y agradecimientos      10

Parte 1: Las claves      13

- 1. Empoderar a los usuarios clave      16

¿Qué significa empoderar?      16

Factor 1: Responsabilidad del usuario en el proyecto      17

Factor 2: Conocimiento del negocio      17

Factor 3: Clima de las comunicaciones      18

Factor 4: Hablar el mismo idioma (jerga del negocio)      19

- 2. Empoderar el equipo del proyecto      21

Empoderar a un desconocido      21

Factor 1: ¿Qué entendemos por equipo?      23

Factor 2: El equipo del proyecto es más que la suma de un jefe de proyecto y unos constructores o proveedores      24

Factor 3: Todos los miembros del proyecto tienen tareas asignadas      25

Factor 4: Los facilitadores también formen parte del equipo del proyecto      25

Factor 5: Conocimiento suficiente del negocio      26

Factor 6: Responsabilidad del jefe de proyecto      26

Factor 7: Canales claros para rendir cuentas      27

Factor 8: El control de todos los aspectos de gestión      27

- 3. Estandarizar las herramientas y los flujos de gobierno del proyecto      29

Factor 1: Los flujos de gobierno son un marco de trabajo para el equipo      29

Factor 2: La normativa de gestión y ejecución no son la finalidad del proyecto, son la herramienta de coordinación      30

Factor 3: Flujo de gestión del proyecto      30

Factor 4: Flujo para la ejecución del proyecto      33

- 4. Focalizarse en la mejora continua y la gestión del cambio      37

Factor 1: Mejora continua es evaluación continua      37

Factor 2: Participación proactiva      38

Factor 3: Agile es la respuesta      38

- 5. La organización necesita establecer una gestión de programa      42

Factor 1: El proyecto tiene implicaciones más allá del área de negocio al cual va destinado      43

Factor 2: La oficina de gestión de programa (PMO)      43

- 6. Establecer un canal constante para evaluar la satisfacción      45

Factor 1: Habilitar canales      45

Factor 2: La satisfacción es bidireccional      45

Factor 3: La gestión de los riesgos y de los problemas es fundamental para la satisfacción      46

Parte 2: Las acciones para fomentar el cambio      49

- 1 y 2. Empoderar e los miembros del equipo      52

La agilidad como herramienta de empoderamiento      52

Definición de la estructura de relaciones      55

Los momentos que acotan el proyecto: El inicio y el cierre del proyecto      59

Los principales hitos en la gestión de un proyecto      60

- 3. Estandarizar las herramientas y los flujos de gobierno del proyecto      67

Los documentos      67

Ciclo de vida de gestión de un proyecto      70

Ciclo de vida de la ejecución de un proyecto      72

- 4. Focalizarse en la mejora continua y la gestión del cambio      77

Mejora continua en el proyecto. Los monográficos      77

Mejora continua en el proceso de gestión. Business Agility      79

Mejora continua en el proceso de gestión. Modelo Agile and Lean methods de Patrick Steyaert      85

- 5. Establecer una gestión de programa      94

La PMO como herramienta para ayudar a los equipos de proyecto      95

Los ciclos de aseguramiento de la calidad      98

- 6. Establecer un canal constante para evaluar la satisfacción      105

Gestión eficiente de los riesgos y problemas      105

Habilitar canales para evaluar la satisfacción      109

Parte 3: Documentos y plantillas del proyecto      113

- Documentos para la gestión del proyecto      116

Documentos de inicio de proyecto      116

Métricas de aseguramiento de la calidad      118

Documentos de seguimiento      119

Documentos de Cierre del proyecto      120

- Documentos de ejecución del proyecto      121

Documentos de propuesta inicial de solución, planificación, riesgos y calidad      121

Documentos de Diseño y Definición      123

Documento de pruebas y aceptaciones      126

Documentos sobre manuales      128

Documentos de Despliegue      129

Anexos      130

- Anexo 1: Glosario de documentos      132

- Anexo 2: Plantillas y contenidos de los principales documentos de proyecto      133

ACT - Acta      133

ARD - Archivo Diario      134

AVI - Análisis de viabilidad      134

CIP - Consenso Interno de Proyecto      135

COP - Coordinación de Proyecto      136

DFU - Diseño Funcional      137

DTE - Diseño Técnico      137

ETP - Especificación Técnica de Pruebas      138

IFS - Informe de Seguimiento      139

Kickoff - Acta de constitución / Kickoff del proyecto      140

MAQ - Métricas y aseguramiento de la calidad      140

MDE - Manual de Despliegue      141

MEX - Manual de Explotación      141

MIA - Manual de Instalación y Administración      142

MOP - Manual de Operatoria      142

MUS - Manual de Usuario      143

PB - Product Backlog      144

PdD - Plan de despliegue      144

PLN - Planificación de proyecto      145

PPR - Plan de Pruebas documentado      145

REQ - Catálogo de Requerimientos      146

RIN - Registro de Incidencias y de Riesgos      146

CPR- Cierre del proyecto      147

- Anexo 3: Catálogo de riesgos usuales      149

- Anexo 4. Referencias      153

Introducción y agradecimientos

Agile es un marco de trabajo apasionante. Y lo es porque nos pone frente al espejo y nos muestra nuestras carencias, pero también nuestro potencial. Después de años de trabajo en la gestión de proyectos, todos nosotros somos capaces de hacer un análisis de todo aquello que compromete la consecución de un resultado de calidad a cada proyecto.

A menudo, nos fijamos solo en carencias técnicas del equipo; pero pienso que esto ni siquiera es del todo cierto en la mayoría de los casos. Después de hacer un gran esfuerzo, hemos organizado las carencias en torno a los siguientes aspectos:

- Las diferentes personas que componen el equipo deben entender su papel.

- El equipo debe sentirse libre de hacer su trabajo en las mejores condiciones posibles.

- Debe existir una secuencia de acciones que permitan al equipo llegar a los resultados de la manera más eficiente y gratificante posible.

- La mentalidad del equipo debe permitir llevar a cabo sus tareas en un clima de búsqueda continua de la calidad.

- El equipo debe tener conocimiento del alcance, la utilidad, la motivación, los objetivos, los beneficios y, sobre todo, el encaje de la solución del proyecto en el catálogo de herramientas de la organización.

- Los miembros del equipo han de poder mostrar su grado de satisfacción en relación con el proyecto, y han de percibir que existe la voluntad de resolver los problemas, tanto personales como del grupo que puedan impactar en el desarrollo del mismo.

Como puede verse, el hecho de que el equipo tenga capacidad para proporcionar un producto de valor va mucho más allá de que se disponga de las habilidades técnicas necesarias. Entran en juego aspectos más psicológicos, de relaciones, de conocimiento organizativo y de gestión del tiempo y de los problemas, que marcan la diferencia a la hora de cumplir los objetivos esperados por la organización en equilibrio con los propios intereses personales y del equipo.

Este documento se ha pensado como una guía de acción, para dar las herramientas que permitan reflexionar sobre la situación de los equipos de proyecto en la organización, y proponer herramientas para mejorar en los aspectos que se derivan de la secuencia siguiente:

Esta secuencia se articula como una receta en forma de claves de éxito, destinada a mejorar el resultado en los proyectos. Las herramientas que propone no siempre tienen su origen en Agile. Hay múltiples propuestas en metodologías tradicionales que aportan mucho valor a la organización de los equipos; pero Agile proporciona una visión que rompe la rigidez, la gestión marcial y jerárquica a la que estamos acostumbrados. Es esta visión la que da mejor respuesta a muchas de las claves de éxito que hemos localizado. El resultado en este documento es un cóctel de propuestas, que intentan aprovechar lo mejor de ambos mundos.

Este documento se ha distribuido en tres partes:

- En la primera parte (“Las claves”) se analizan de cada una de las claves de éxito de un proyecto.

- En la segunda parte (“Las acciones para fomentar el cambio”), se describen recomendaciones, propuestas y herramientas para profundizar en la mejora de la organización para cada una de las claves descritas en los puntos anteriores. Se hace especial énfasis en la descripción de un flujo de gobierno de proyecto que sea permeable a cada una de las claves de éxito descritas.

- En la tercera parte (“Documentos y plantillas del proyecto”), se desarrolla una propuesta de documentos que pueden ser de aplicación en el flujo de gobierno descrito en la sección anterior.

Este documento no habría sido posible sin la colaboración desinteresada de muchos amigos y compañeros de profesión que me han aconsejado sobre todo tipo de aspectos de contenido, claves de éxito, expresiones, orientación de las soluciones y, en definitiva, sobre todos los aspectos que han convertido esta tarea de creación en un placer personal.

Quiero agradecer especialmente la colaboración de Manolo García (compañero del Área de Tecnología de la UOC) por su visión siempre de calidad, debido a su larga experiencia en proyectos de mucha complejidad. También quiero agradecer la colaboración de Helena Gener (amiga en múltiples proyectos de consultoría) por su visión pausada y orientada a las personas. Me ha ayudado a encontrar un acento en este documento que se aleja de la visión bélica en la que solemos trabajar. No quiero olvidar en estos agradecimientos los consejos de Alex Romero (compañero del Área de Tecnología de la UOC) y su punto de vista como facilitador, que me ha ayudado a reflejar en este trabajo los aspectos de análisis de la necesidad y la mediación. También quiero agradecer la inestimable ayuda recibida por Francesc Tataret, (gran profesional en el mundo de la edición) por sus correcciones de estilo y comentarios múltiples que han redondeado muy positivamente esta obra.

Por último, no quiero olvidar a todas aquellas personas que, a lo largo de estos años, directa o indirectamente, me han ayudado a entender que la gestión de proyectos es, por encima de todo, un reto de mejora continua y autoconocimiento.

Parte 1: Las claves

En la gestión de cualquier proyecto hay una serie de factores recurrentes que afectan directamente sobre el éxito. Estos factores tienen mucho que ver con la relación con les persones adecuadas que colaboran en el proyecto, i de su empoderamiento en el equipo; el uso de herramientas y métodos para poder coordinarse cómo un equipo eficiente y transparente; i de cómo hacer el seguimiento de las tareas y situación del proyecto. Todos estos son elementos que, si somos conscientes de la necesidad de tenerlos presentes en el proyecto des del primer momento, favorecerán enormemente nuestra misión en el proyecto cómo gestores y responsables. Los factores que trataremos a continuación son los siguientes:

1. Empoderar los usuarios clave

2. Empoderar al equipo del proyecto

3. Estandarizar las herramientas y el flujo de trabajo en la gestión y ejecución del proyecto

4. Focalizarse en la mejora continua y la gestión del cambio

5. Establecer una gestión de programa

6. Establecer un canal constante para evaluar la satisfacción

Empoderar a los usuarios clave

Empoderar al equipo del proyecto

Estandarizar las herramientas y el flujo de trabajo en la gestión y ejecución del proyecto

Focalizarse en la mejora continua y la gestión del cambio

Establecer una gestión de programa

Establecer un canal constante para evaluar la satisfacción

1. Empoderar a los usuarios clave

Los factores clave para el empoderamiento del usuario son los siguientes:

1. Asegurar que los usuarios clave asumen su responsabilidad como motores del cambio y no delegan en terceras personas.

2. Asegurar que los usuarios clave asignados al proyecto tienen un conocimiento profundo sobre el negocio y sobre la situación actual del flujo de negocio de los equipos usuarios.

3. Asegurar un clima de colaboración entre los responsables del proyecto, proveedores, desarrolladores y los usuarios clave.

4. Asegurar un conocimiento común del lenguaje del negocio y técnico (hablar el mismo idioma).

¿Qué significa empoderar?

Empoderar debe entenderse, no desde una semántica de poder, sino de responsabilidad. La responsabilidad de todos los actores del proyecto es clave para garantizar un buen flujo de las comunicaciones, las relaciones y el cumplimiento de los objetivos del proyecto.

Los usuarios clave son un elemento especialmente importante para garantizar el éxito final del proyecto y de sus productos. Un usuario clave que no asume sus responsabilidades en el proyecto puede generar serios problemas en la comprensión de la necesidad y de la solución, que pueden acabar en fracaso o en la cancelación del proyecto.

Metodologías tradicionales (y extensivas) como PRINCE2 hace años que son conscientes de la importancia del equilibrio de responsabilidades entre todos los participantes, y establecen mecanismos de dirección, seguimiento, cumplimiento de la calidad y aceptación muy estrictas.

Con la aparición de marcos de trabajo ágiles puede parecer que estos aspectos son más laxos, e incluso podemos pensar que son inútiles, pero esto es un elemento más de confusión en la vorágine actual de asimilación desordenada de Agile.

Factor 1: Responsabilidad del usuario en el proyecto

Si algo hace Agile, es precisamente poner en el centro de la gestión al usuario, y dotar de las herramientas comunicativas y organizativas necesarias para establecer un canal fluido (o ágil) de comunicación y seguimiento de sus tareas en el proyecto.

En este sentido es importante asegurar que el usuario clave realmente asume la responsabilidad que le corresponde. Las responsabilidades no se delegan; el trabajo sí puede delegarse. Es decir: el usuario clave debe asegurarse de que él u otra persona a la que delegue cumple las metas que se le encomienden. Pero la responsabilidad en el desempeño de las metas pactadas será del responsable y no de los delegados.

Es bastante habitual la tendencia de que el usuario clave confíe la participación en el proyecto, en parte o todo su equipo. La dirección del proyecto en este caso debe ser clara. Las decisiones y la responsabilidad corresponden a los responsables (usuarios clave), y no a los delegados.

Factor 2: Conocimiento del negocio

Una premisa importante que proporciona tranquilidad en la gestión de un proyecto es la elección acertada de los usuarios clave. Los usuarios clave los elige el negocio y no el proyecto; y es responsabilidad suya hacer una elección adecuada y realista. Un usuario clave es una persona que, además de su trabajo habitual, dedica un tiempo (a menudo considerable) en colaborar en la definición de las necesidades, y en la aceptación posterior de los resultados.

El usuario clave es una persona que conoce el negocio en detalle, dispone del tiempo imprescindible para tener la interlocución necesaria con los equipos del proyecto y con los usuarios finales de la solución, para asegurar el máximo de consenso en la adopción de la solución diseñada.

A menudo el usuario clave debe dedicar un tiempo considerable en explicar al equipo del proyecto cuál es su flujo de trabajo (flujo del negocio), para entender bien cuál es la situación actual, y cómo esta afecta al producto final. Esta acción es fundamental, y a la que a menudo no se dedica el tiempo necesario, o simplemente no se explican todos los detalles importantes. Uno de los principales generadores de incertidumbre y confusión en el proyecto y en las personas que participan, tienen su origen en un desconocimiento total o parcial de cómo trabaja el usuario y si la solución desarrollada es adaptable a su flujo de trabajo.

La solución, mirada únicamente por su alcance, a menudo parece infalible, pero examinada desde el flujo del negocio pueden hacer aparecer problemáticas inicialmente ocultas. Una de las responsabilidades más claras asignadas al usuario clave, es asegurarse de que el equipo del proyecto entiende el negocio.

Factor 3: Clima de las comunicaciones

Para poder asimilar toda la información necesaria para diseñar una solución completamente satisfactoria, debemos asegurar un buen clima de comunicación con estos usuarios. Esto solo es posible si tenemos en cuenta una serie de factores que deben quedar claros desde el primer momento:

- La responsabilidad de los usuarios clave en el proyecto.

- Las metas, las tareas, las reuniones y, en definitiva, el peso de estas responsabilidades por parte de los usuarios clave.

- El alcance del proyecto (que se hace y que no se hace).

En el punto anterior hablábamos de que la principal responsabilidad del usuario clave es asegurarse de que el equipo del proyecto entiende la problemática a cubrir por la solución. En este sentido, hay algunos ítems que afectan a la forma de comunicar o en que se comunica que a menudo genera malentendidos en el equipo del proyecto. Para completar la lista anterior podemos añadir que el usuario clave debe:

- Debe ser abierto, en cuanto a la definición de la situación actual del flujo de trabajo de su competencia. Explicando la realidad de su día a día de forma clara, suficiente y completa.

- Debe ser pedagógico en sus explicaciones. El equipo del proyecto probablemente no conoce todos los detalles de su flujo de trabajo. El usuario clave debe focalizarse en asegurar que el equipo comparte con él el detalle de la problemática.

- Debe entender el alcance y los límites del proyecto. El usuario clave debe tener muy presente el alcance del proyecto que se ha pactado, los límites de la tecnología, los límites de la organización y cualquier otro factor que afecte lo que él entiende como la solución ideal.

- Debe ser consciente de que la organización es una maquinaria compleja de múltiples partes, donde la solución idónea para él puede ser un gran escollo para otras áreas, departamentos o personas de la organización. Lo mejor para un departamento no necesariamente tiene que ser la mejor de las soluciones posibles.

Un proyecto es una acción de equipo en la que suele participar un grupo heterogéneo de personas, con diferentes grados de conocimiento o especialidad. Es necesario generar un clima de transparencia en el trabajo y asunción de responsabilidades, para favorecer la generación de un clima de confianza que facilite la construcción de la solución idónea. La transparencia es un elemento muy importante desde el primer momento. Si el usuario clave no tiene todo el conocimiento sobre la problemática o sobre el flujo del negocio; no quiere o no puede explicar ciertos aspectos de la problemática; no sabe explicar algunas cuestiones desde una perspectiva que sea comprendida por el equipo; o no sabe desligarse de aspectos emocionales que afectan su flujo de trabajo de la problemática que trata de resolver, el equipo del proyecto nunca estará seguro de haber comprendido todo lo necesario para aplicar la solución.

El equipo de proyecto está aquí para resolver una (y sólo una) problemática concreta. No está aquí para resolver todos los problemas del departamento o de la organización. No podemos explicar al equipo del proyecto otros problemas que nos preocupan. Hemos de ser conscientes del alcance previamente pactado y no confundir mezclando problemáticas, ni maquillándolas para que parezcan estrechamente relacionadas con el objeto que el equipo ha venido a resolver.

Factor 4: Hablar el mismo idioma (jerga del negocio)

Todo el mundo debe entender lo mismo respecto al alcance y con respecto al flujo del negocio del usuario. El equipo del proyecto y los usuarios deben hablar el mismo idioma. El único idioma válido en este sentido es el idioma del negocio, con todas sus particularidades y jerga. Únicamente así podemos estar seguros de que el alcance del proyecto es bien entendido por todas las partes.

¿Qué hemos visto en esta sección?

- El usuario clave pasa a estar en el centro de la gestión.

- La elección de los usuarios clave debe ser una tarea consciente y soportada por la organización, ya que de una elección acertada depende en gran parte el éxito del proyecto.

- Los usuarios clave tienen el conocimiento suficiente del negocio y del problema a resolver, y su principal misión es asegurar que el equipo del proyecto entiende el negocio.

- Los usuarios clave se caracterizan por ser abiertos, pedagógicos, entienden el alcance, los límites y la complejidad de la organización; y asumen su responsabilidad en el proyecto.

- Los usuarios clave son el motor del cambio y no delegan la responsabilidad en terceras personas.

- Hay que asegurar un buen clima de comunicación y colaboración, mediante el fomento de la confianza y la transparencia.

- El único idioma de relación es el del negocio.

2. Empoderar el equipo del proyecto

Una vez tenemos empoderado al usuario clave, el siguiente paso es incluirlo dentro de la dinámica del proyecto, y dotar al equipo de las herramientas que faciliten su organización interna y su coordinación, un marco de trabajo que les permita trabajar de forma ordenada y racional, y un ámbito de decisión que les permita la operatividad, la eficiencia y la autonomía.

Los factores clave para el empoderamiento del equipo del proyecto son los siguientes:

1. El equipo debe disponer de espacios y tiempo para alcanzar el clima necesario para llegar a acuerdos internos y trabajar colaborativa y constructivamente. Un equipo es tal porque trabaja en equipo, y no sólo para que sean un grupo de personas vinculadas por un proyecto.

2. El equipo es algo más que la suma de un jefe de proyecto y proveedores. Son todas aquellas personas con responsabilidad sobre la infraestructura, la arquitectura y la calidad. Todos ellos forman parte también del equipo del proyecto.

3. Todos los miembros del equipo tienen tareas asignadas, donde se espera de todos la máxima implicación.

4. También son parte del equipo las personas que tienen la misión en la organización de facilitar puentes entre el negocio y la tecnología (los facilitadores). Entre sus atribuciones, cuentan con el conocimiento fluido sobre la cadena de valor de la organización.

5. Los jefes de proyecto deben tener un conocimiento suficiente sobre la tecnología que afecta el proyecto, y sobre las operativas de gestión que le permitan afrontar su trabajo con garantías.

6. Los jefes de proyecto deben tener un conocimiento suficiente sobre el área de negocio y sobre la organización para poder ejercer su trabajo.

7. Los jefes de proyecto son los directores operativos del proyecto. Tienen la máxima responsabilidad, y están para tomar decisiones y buscar consensos.

8. Los jefes de proyecto rinden cuentas al grupo de seguimiento directivo que se haya establecido que los protege para evitar que el proyecto se vea influido de forma externa.

9. El jefe de proyecto controla todos los aspectos de la gestión sin excepción.

Empoderar a un desconocido

Las responsabilidades de un gestor (o jefe) de proyectos han cambiado mucho en los últimos años. Al principio las áreas financieras de la empresa contaban con la ayuda de profesionales informáticos, en dependencia directa del departamento financiero. El contable representa la dirección del proyecto, donde éstos se centraban en los flujos de contabilidad y en la cadena de producción.

Con el crecimiento de estas empresas se incrementa la complejidad. Los flujos financieros dejan de ser lo más importante y aparecen otros conceptos, cómo las ventas, el márketing, la logística, el soporte al cliente, la calidad, la búsqueda y el aseguramiento del conocimiento.

Aquel profesional de la informática, usualmente un todo terreno en la empresa comienza a adaptarse a la nueva situación, mucho más diversa que antes, y el departamento tecnológico empieza a vestirse de elementos de dirección y gobierno de la tecnología en la empresa. Primero con los sistemas y el hardware, y posteriormente con las aplicaciones.

A partir de aquí comienza una nueva actitud en las relaciones Tecnología-Empresa que se extiende durante años, y que se caracteriza por la externalización. Primero es una externalización de la relación; se trata en el área tecnológica como un área externa. Y esto ocurre también con otras áreas (finanzas y RRHH son buenos ejemplos). Independientemente de que estas áreas ocupen el mismo espacio que el resto de la empresa, la actitud es de externalización.

Con el tiempo el conocimiento del negocio deja de ser un asunto global. Aparecen islas de conocimiento que son exclusivas del área de competencia. Esto es un proceso lógico derivado de la especialización y del aumento de la complejidad organizacional, pero que, llevado al extremo, termina con un desconocimiento de la cadena de valor de la misma empresa.

La complejidad llega mucho más lejos de la simple compartimentación en áreas empresariales. La informática y las telecomunicaciones avanzan a un ritmo acelerado, que provoca también un aumento de la complejidad en la gestión de los recursos tecnológicos de la empresa. El departamento tecnológico se ve obligado a su vez a compartimentar por áreas de conocimiento. Más allá de la simple división de Sistemas y Aplicaciones, aparecen otras subáreas especializadas, como seguridad, arquitectura, integración, oficinas de gestión del cambio, consultoría, oficinas de gestión de la calidad o UX.

Finalmente, el gestor tecnológico en la empresa llega a ser un desconocido (tanto en el interno de la misma área tecnológica, como por el resto de la empresa) al que la organización debe depositar su confianza en la gestión de un proyecto. El reto hoy es empoderar a esta persona ya su equipo.

Factor 1: ¿Qué entendemos por equipo?

Un equipo es un conjunto de personas que colaboran para el logro de unos objetivos comunes. Esta sencilla definición a menudo es olvidada para pasar a ser "un grupo de personas que trabajan juntas". Para que un grupo pase a ser un equipo es necesario que:

- Los miembros del equipo han de trabajar juntas: En contacto directo. Han de comunicarse y conocerse.

- Los miembros del equipo han de tener unas responsabilidades claras: Para que un grupo sea un equipo, cada miembro debe ser perfectamente consciente de cuál es su papel en el equipo.

- Cada miembro del equipo ha de tener algo que hacer: Asumir responsabilidades significa ser conscientes de que tenemos una misión en el equipo y que aportamos un valor. En un equipo no hay personas que van por libre. Cada miembro tiene una tarea y unos objetivos que cumplir.

- Los miembros del equipo han de generan un clima constructivo y colaborativo: Han de poder explicar abiertamente lo que hacen, y lo que esperamos de los demás. Presentan resultados, piden ayuda, etc.

Para alcanzar este nivel de colaboración, el equipo del proyecto debe disponer de espacios y tiempo para alcanzar el clima necesario para llegar a acuerdos internos y trabajar colaborativa y constructivamente. Esto es especialmente necesario en aquellos estamentos que se configuran como servicio, y que no tienen visión de los proyectos en los que se ven abocados a trabajar. No se puede colaborar realmente en un proyecto desde una perspectiva de trabajo en servicio.

Los servicios son estamentos reactivos (push). Es decir, tenemos un equipo de personas preparadas para resolver problemáticas en un aspecto concreto (operaciones, disponibilidad de sistemas, gestores de bases de datos, diseño de interfaces, etc.). Su modus operandi genérico es esperar una petición y actuar en ese momento con la información que se adjunta. Esto no cuadra con la idea de proyecto, porque:

- No han participado en el proceso de creación y generación de la petición.

- No tienen control sobre la dimensión de las peticiones que les llega, sobre su complejidad, sobre su cantidad ni su criticidad.

- A menudo la petición se enfoca como problema, que debe resolver el servicio, y que se podría haber evitado.

- Con facilidad, la resolución de la petición se convierte en una auditoría, donde el servicio da un OK o NOK a lo que ha generado la petición, constriñendo aún más la capacidad del servicio para generar acciones de valor focalizadas en resolver la cuestión.

Los proyectos son estamentos activos (pull). Al inicio del proyecto se establece un compromiso de dedicación para cada una de las personas del equipo. Este compromiso puede renegociarse en cualquier momento, según las necesidades. Pero de momento el jefe de proyecto sabe con quién puede contar, cuándo y cuánto. Dentro del equipo todas las necesidades profesionales del proyecto deben quedar cubiertas, de forma que cualquier necesidad se pueda resolver internamente. No hay concepto de servicio, sino de roles profesionales que aportan soluciones a los problemas que aparecen, en el momento en que aparecen (o cuando sea necesario encontrar soluciones) y se resuelve con la colaboración y conocimiento de todos los miembros del equipo.

Factor 2: El equipo del proyecto es más que la suma de un jefe de proyecto y unos constructores o proveedores

El equipo del proyecto son todas aquellas personas con responsabilidad sobre la infraestructura, la arquitectura y la calidad. La complejidad de las organizaciones repercute en una mayor complejidad en la organización interna del departamento tecnológico; donde se crean subdepartamentos especializados en ciertos aspectos del software, hardware, seguridad, procesos o gestión.

Un elemento más de complejidad suele ser la externalización de los servicios, que afecta a muchas operativas del área tecnológica, pero especialmente al desarrollo de soluciones. Llegando al extremo en que el área tecnológica adquiere un rol de liderazgo de proyecto, con equipos humanos y recursos externalizados.

En la constitución de un proyecto, es usual asignar un gestor o jefe de proyecto interno, con equipos operativos externos. En el proceso nos olvidemos de la participación de otros elementos críticos para el éxito del proyecto. Esto suele ser muy visible en la participación del equipo de Operaciones (pero no únicamente con este grupo). El equipo de Operaciones es el eterno olvidado en la constitución de un proyecto, donde debería participar desde el principio. Cuando son inexcusablemente necesarios aparecen conflictos en torno a cómo acomodar su participación, y su priorización interna sobre los procesos de operaciones necesarios para el proyecto.

En estos escenarios suelen aparecer procesos en los que nadie tiene un conocimiento completo. Se inicia entonces un mecanismo de relación basado en favores, presiones y abuso de tareas declaradas como críticas. Los equipos se ponen en tensión, se traslada la responsabilidad hacia las partes más débiles y no hacia quienes pueden aportar soluciones. Cuando intervienen colaboradores externos a menudo los canales de comunicación habilitados no facilitan la resolución de las tareas ágilmente; y las operaciones que se necesitan llevar a cabo (y que a menudo nos parecen sencillas y claras) eternizan y no terminan bien.

Factor 3: Todos los miembros del proyecto tienen tareas asignadas

Todo el mundo debe tener una responsabilidad clara en el proyecto; y se pide de todos la máxima implicación en el proyecto. Algunas personas piensan que participar en un proyecto es opinar. Aparecen, dicen lo que les apetece decir, y se van. Debe evitarse esta actitud.

Toda persona que participa en un proyecto tiene una responsabilidad, y la asunción de esta responsabilidad es deriva necesariamente en la asunción de una serie de tareas asignadas. Es bueno evitar la presencia de opinadores sin trabajo en el proyecto.

Factor 4: Los facilitadores también formen parte del equipo del proyecto

Algunas organizaciones dedican recursos a asegurar que el conocimiento funcional y de negocio no se pierde; de forma que este conocimiento está en manos de un equipo de personas que vela por transmitirlo cuando es necesario, y por su coherencia situacional y evolutiva. Estas personas también son parte del equipo del proyecto.

El jefe de proyecto necesita estar asesorado por alguien con una visión más transversal del negocio que la que puedan tener los usuarios clave y el mismo, para asegurar que las situaciones descritas y las propuestas de solución son coherentes con este conocimiento desde una perspectiva global.

Estas personas, a las que podemos llamar facilitadores también pueden ejercer el papel de negociadores en situaciones de conflicto y dar soporte a los usuarios clave en la identificación de requerimientos. Los facilitadores requieren de una formación muy específica y de la asunción de un rol muy concreto; ya que su tarea, ejecutada de manera inapropiada, puede ser generadora de conflicto entre los participantes en un proyecto y con personas externes o interesadas.

Los facilitadores deben ocupar un lugar de equidistancia entre los interlocutores, y deben basar sus intervenciones en función de los impactos sobre los procesos de trabajo del área de negocio; o bien si generan consecuencias negativas fuera del área destinataria del proyecto. No toman decisiones unilaterales que afectan el proyecto, y no son el abogado del usuario.

Factor 5: Conocimiento suficiente del negocio

Un factor muy importante corresponde al hecho de que los jefes de proyecto, aparte del conocimiento tecnológico suficiente; y los conocimientos de gestión del proyecto y de los equipos; deben tener un conocimiento suficiente sobre el área de negocio y sobre la organización, para poder ejercer su trabajo. Esto implica no solo conocer el flujo de negocio del departamento en cuestión, sino también conocer como hablan en ese departamento.

Esta es la eterna asignatura pendiente en las organizaciones actuales donde el jefe de proyecto ha perdido contacto con las áreas usuarias, o incluso ni siquiera está presente en la organización. Para suplir esta carencia el jefe de proyecto cuenta con los mecanismos siguientes:

- Dotarse de los usuarios clave adecuados para que puedan ayudar en el conocimiento del flujo de trabajo del área.

- Colaborar con los facilitadores de la organización que conocen el flujo organizativo, conocen las personas más adecuadas de la casa, dentro y fuera del área objeto del proyecto, así como el impacto o las repercusiones que el resultado del proyecto puede provocar sobre departamentos o sobre los flujos de trabajo.

- Entender el flujo y el idioma para que la documentación y las comunicaciones sean entendidas por el usuario sin necesidad de traducciones.

Factor 6: Responsabilidad del jefe de proyecto

Los jefes de proyecto son los directores operativos del proyecto. Tienen la máxima responsabilidad, y están para tomar decisiones y buscar consensos. De este hecho deben ser conscientes todos los participantes. El objetivo de todo proyecto es la creación de un producto útil. Ello conlleva una acción continua de negociación y consenso, pero por encima de esto, conlleva la toma de decisiones que no siempre deja contento a todo el mundo.

En este sentido el jefe de proyecto toma decisiones en función de los acuerdos que negocio, intereses de todos los participantes, y la misma organización. Tomar decisiones no necesariamente significa el establecimiento de una jerarquía al interno del equipo, donde la figura máxima es el jefe del proyecto. Más bien tomar decisiones significa facilitar el clima óptimo en el equipo para que este protagonice las decisiones y lidere las acciones necesarias.

Esto representa un cambio en el paradigma tradicional del jefe de proyectos, que pasa a ser un impulsador en el proyecto más que un mando. Esto requiere confianza en el equipo, y proactividad por parte de los integrantes. Un equipo pasivo no es un buen punto de partida para comprometerse con un plan conjunto. Se necesita pedagogía para motivar la autoorganización necesaria para que el equipo sea el motor del proyecto de forma continua: Las decisiones no se toman un día D a una hora H. Se toman cada día, cuando es necesario.

Factor 7: Canales claros para rendir cuentas

Relacionado con el punto anterior, la única forma de garantizar que el proyecto realiza las acciones, y que estas son parejas con las decisiones que se han tomado, es estableciendo un sistema de información o seguimiento entre las personas que toman las decisiones. Los jefes de proyecto rinden cuentas al grupo de seguimiento directivo que se haya establecido.

Rendir cuentas es la acción de casar las decisiones tomadas con las acciones realizadas en el proyecto. Para que esto sea coherente, las personas que esponsorizan el proyecto (que tienen la responsabilidad ante la dirección de la organización) y las direcciones de las áreas y departamentos afectados por el proyecto, han de ser las mismas que participan en el seguimiento.

El grupo de seguimiento es una estructura de personas y tiempo creada explícitamente para el proyecto. El grupo de seguimiento tiene la potestad de influir sobre algunas variables del proyecto, como es el alcance, el presupuesto, la disponibilidad de recursos o la mediación de los riesgos críticos. Siempre de forma consensuada con el equipo del proyecto, que tiene como misión principal en este aspecto, hacer visible el equilibrio entre realismo, viabilidad y deseo.

Una de las misiones de este órgano de seguimiento y de las personas que lo componen consiste a proteger el equipo de proyecto para evitar que se vea influido de forma externa. Parece una obviedad, pero muchos proyectos padecen este tipo de interferencias y generan conflicto entre lo que inicialmente se decide, i lo que finalmente se realiza.

Factor 8: El control de todos los aspectos de gestión

El último factor en esta sección corresponde al control de las variables del proyecto.

1. Recursos internos, externos y proveedores.

2. Calendario y planificación del proyecto.

3. Presupuesto, compras, contrataciones, negociaciones de las gestiones del cambio, gestión de las limitaciones presupuestarias, priorización.

4. Determinación de las normas de calidad estándar (las establecidas por la organización) y particulares (según las particularidades del proyecto): calidad documental, flujo de gestión, flujo de ejecución, calidad del código, calidad del producto, flujo de testing y política de aceptaciones.

La atribución principal del jefe de proyecto, como ya hemos comentado, es el control de estas variables y, para poder controlarlas, ha de disponer de la libertad suficiente para poder tomar decisiones. Este es el principal factor que proporciona al jefe de proyecto de la atribución que se espera en su gestión.

¿Qué hemos visto en esta sección?

- Un equipo es tal porque trabaja en equipo, y no sólo para que sean un grupo de personas vinculadas por un proyecto.

- Un equipo es un conjunto de personas que colaboran para el logro de unos objetivos comunes, y que se caracterizan por crear un clima constructivo y colaborativo, trabajan juntos y saben cuál es su misión individual y como grupo.

- El equipo del proyecto es algo más que la suma de un jefe de proyecto y unos constructores o proveedores.

- Todos los miembros del equipo tienen tareas asignadas en el proyecto, y todo el mundo sabe lo que tiene que hacer.

- Los jefes de proyecto deben tener un conocimiento suficiente sobre la tecnología que afecta el proyecto, sobre las operativas de gestión y sobre el área de negocio en la que se aplica la solución.

- Un equipo se caracteriza por la proactividad, y por tanto no convive bien en entornos con exceso de líneas de servicio o auditorías.

- Rendir cuentas es la acción de casar las decisiones tomadas con las acciones que se han llevado a cabo en el proyecto.

3. Estandarizar las herramientas y los flujos de gobierno del proyecto

Una vez que todas las personas que intervienen en un proyecto están convenientemente empoderadas, conocen sus responsabilidades y cuentan con el apoyo de la organización adecuado a su nivel de responsabilidad, es necesario que trabajen como un equipo. Un buen punto de punto de partida para trabajar como un equipo es la buena voluntad y la actitud constructiva, pero además hacen falta herramientas y método.

Para entender la importancia de la estandarización de herramientas es necesario tener presente lo siguiente:

1. Las herramientas, la documentación y los flujos de gestión y ejecución son el marco de trabajo para el equipo y deben constituirse cómo un estándar en la gestión de proyectos de la organización.

2. La normativa de gestión y ejecución no son la finalidad del proyecto, son la herramienta de coordinación.

3. La documentación y los marcos de trabajo deben constituirse cómo un estándar en la gestión de proyectos de la organización.

Factor 1: Los flujos de gobierno son un marco de trabajo para el equipo

Los flujos de gobierno son un compromiso de todos los equipos de proyecto para todos los proyectos. Han de ser realistas y asumibles, y han de ser suficientemente flexibles para acomodar las visiones, estilos de gestión y marcos de trabajo que sean de uso habitual en la organización, así como las necesidades particulares del proyecto.

El jefe de proyecto vela por asegurar que estos flujos son comprendidos y utilizados por todo el equipo. El equipo por su parte vela para que las acciones establecidas en estos flujos, así como los documentos y las herramientas son útiles para su trabajo, la facilitan y están enfocadas en la consecución de un producto de calidad.

Factor 2: La normativa de gestión y ejecución no son la finalidad del proyecto, son la herramienta de coordinación

Los flujos de gestión y ejecución del proyecto, las herramientas y plataformas de soporte para el equipo del proyecto, la documentación y los marcos de trabajo deben constituirse como un estándar de uso obligado en la gestión de proyectos de la organización y, por tanto, deben ser conocidos en detalle por los jefes de proyecto, usuarios clave y proveedores.

Dicho esto, hemos de ser conscientes que son simples herramientas y un proyecto no consiste en el uso obsesivo de plantillas y aplicaciones de gestión, si no en la consecución de unos resultados de calidad. Las herramientas nos ayudan a conseguirlo, pero no son la finalidad del proyecto. Los jefes de proyecto tienen la responsabilidad de conocer y hacer conocer los marcos y los flujos de trabajo, y defenderlos y utilizarlos de la forma más conveniente para el proyecto.

Por otro lado, hemos de tener presente que los flujos, las herramientas y las normativas no son artefactos para crear una “máquina de gestionar automática”, donde los proyectos se resuelven por el simple seguimiento de unas instrucciones. Los proyectos son siempre complejos y requieren de interacción humana y decisiones basadas a menudo en variables no cuantificables. Por mucho que insistamos en diseñar la máquina de gestionar perfecta, y el jefe de proyectos se pase horas informando sistemas de control, siempre será necesario intervenir con visión humana, sobre todo en momentos de crisis.

Si la organización no contempla en su normativa la gestión ágil, y el equipo del proyecto encuentra adecuado aplicar agilidad al proyecto, nada debería frenar una vía para cambiar las normas. Los equipos de proyecto son la puerta de entrada de nuevas formas de hacer, y vetar esto es empobrecer la organización. Pero no todo vale. Una vez el equipo del proyecto ha tomado algunas decisiones sobre como trabajar, los cambios repentinos no son positivos.

Por último, más allá del seguimiento de un flujo de trabajo y el cumplimiento de una serie de normativas, hemos de asegurar de que disponemos de normas de calidad en el trabajo y que estos son comprendidos y aceptados en el equipo, porqué esto marcará el día a día en el trabajo interno, el avance del proyecto y las aceptaciones.

Factor 3: Flujo de gestión del proyecto

El flujo de gestión del proyecto es la herramienta que sirve al equipo del proyecto para determinar los aspectos siguientes:

1. Los requerimientos necesarios para poder iniciar el proyecto.

2. Los requerimientos necesarios para poder determinar la finalización del proyecto.

3. Las herramientas, documentación y acciones necesarias para el seguimiento del proyecto.

4. La información de la situación del proyecto, y su accesibilidad por el mismo equipo, por los estamentos de seguimiento, y por cualquier interesado externo al proyecto.

Para poder tener control de estos elementos y poder ofrecer información fiable, es necesario crear un sistema que nos ayude a soportar la documentación útil, el control de las desviaciones y la infraestructura tecnológica accesible por los interesados. Podemos determinar tres pilares que nos ayudan a articular la gestión del proyecto:

En la parte “Parte 2. Las acciones para fomentar el cambio”, encontraras una extensa propuesta de flujo de gobierno, donde quedan reflejadas las principales acciones e hitos en la gestión de un proyecto, con especial atención a la calidad de los documentos, los repositorios y la gestión de riesgos.

Los riesgos

Una buena práctica en la gestión del proyecto es situar los riesgos como pieza central de la gestión. Implantar un método de vigilancia activa de riesgos, que sea común y que facilite la detección temprana de problemas o peligros del proyecto, así como planificar y articular las acciones de mitigación. Sin olvidar las acciones que nos permitan realizar el seguimiento de la situación de los riesgos de forma periódica dentro del equipo y con los órganos de seguimiento.

Focalizarse en los riesgos ayuda al equipo a preguntarse constantemente que puede salir mal[1]. La gestión centrada en riesgos requiere de un flujo de gestión que permita aclarar en todo momento la situación de un riesgo, el plan de mitigación, la situación de las acciones del plan y, por encima de todo, quienes son los responsables de las acciones de control y mitigación.

La identificación de los riesgos es una fuente de problemas entre los diversos participantes del proyecto. La descripción de un riesgo ha de ser concreta, entendible para todas las partes, sincera y no alarmista; ha de comunicarse de forma eficaz, inmediata y segura. Deben documentarse para poder hacer un seguimiento efectivo.

La localización de riesgos de forma continuada nos sirve para mejorar el proyecto o el negocio y debe de ser especialmente cuidadoso cuando éstos hacen referencia a personas, grupos o formas de hacer que no siempre comprendemos. En la descripción del riesgo no debe eludirse la problemática que genera el riesgo.

Los riesgos que no tienen solución no son un riesgo en el proyecto, son una alteración del alcance. Los riesgos aplicables a personas no son un riesgo en el proyecto; son un elemento del que la organización necesita tomar una decisión.

Los repositorios

Otro elemento importante para la correcta aplicación de los flujos de gobierno del proyecto corresponde a las herramientas y repositorios que permiten registrar, almacenar y validar los elementos, o subproductos necesarios para la construcción del resultado del proyecto. Estos son: código, paquetes de test, documentación de análisis y diseño, informes de seguimiento, actas de reunión, etc.

El repositorio debe ser accesible para todos los participantes del proyecto, y por todas aquellas comunidades que tienen un interés en conocer la situación, alcance u objetivos del proyecto. Cuando decimos accesible, no queremos decir sólo localizable, sino (y es el tema de fondo en esta sección) que deben tener una estructura estándar que facilite la búsqueda de documentos y contenidos concretos. Todos los proyectos repositados han de compartir una estructura común que facilite la búsqueda de documentos.

Los documentos

En cuanto a los documentos; los formatos, contenidos y mínimos de calidad documental deben ser conocidos por todas las partes. Los documentos pasan por un flujo de revisión y aceptación al igual que cualquier otro entregable del proyecto.

El uso de plantillas, guías de uso y estándares documentales son muy recomendables para conseguir un nivel documental de calidad aceptable para todas las partes del proyecto. Tener una documentación de calidad no significa hacer documentación extensa y exhaustiva hasta el aburrimiento. Debemos encontrar el equilibrio para conseguir una documentación útil para el equipo, y sin que la creación de la documentación se convierta en el objetivo principal del proyecto: Los medios por encima de la finalidad.

Fabricar la documentación del proyecto tiene una parte mecánica, por lo que las plantillas y otras herramientas nos pueden ayudar, y tiene una parte que depende de nuestra habilidad para plasmar la información necesaria en el documento, y resaltar lo verdaderamente útil. La capacidad de síntesis, la claridad en la expresión, la ordenación de los contenidos, el uso de herramientas de ingeniería por encima del uso excesivo de la narrativa, son claves para la construcción de una buena documentación del proyecto.

Para las organizaciones es importante estandarizar el nivel de contenidos de la diferente documentación del proyecto. Dónde encontrar cierta información, como describirla, con qué nivel de detalle. Todos estos aspectos ayudan mucho de cara al mantenimiento y evolución posterior del producto del proyecto, con independencia de las personas que participaron en la creación del producto y de la documentación.

Factor 4: Flujo para la ejecución del proyecto

La ejecución del proyecto es mucho más exigente en tiempo y dedicación de lo que nos podemos imaginar. Quien piense que es el momento de pasar la pelota al proveedor y que ya nos avisará cuando haya terminado, es que no entiende la idea de proyecto y de trabajo en equipo.

Las claves para determinar un flujo de ejecución de proyectos adecuado son las siguientes:

1. Conocer el flujo: Todo el equipo implicado en el proyecto ha de conocer el flujo y utilizarlo de forma proactiva.

2. Participación activa de los usuarios clave: La ejecución involucra de manera activa a todos los miembros del equipo y especialmente el grupo de usuarios clave asignados al proyecto.

3. Los momentos: El seguimiento de un flujo comporta una serie de acciones o momentos en que algunas o todas las partes se ven implicadas y necesitan colaborar. Es imprescindible que esto sea así.

Conocer el flujo

El seguimiento de un flujo de ejecución es especialmente importante para el equipo del proyecto, ya que serán ellos los protagonistas de las principales acciones de ejecución y los que informarán de la consecución de los hitos establecidos. Este flujo debe ser conocido y utilizado de manera proactiva no sólo por los desarrolladores, sino por todos los miembros del equipo.

En la ejecución todo el protagonismo esta centrado en la construcción o implantación del producto, sus aceptaciones, sus problemas y su calidad, y es responsabilidad del equipo del proyecto alertar sobre los problemas, presentar los resultados parciales y informar sobre la evolución a medida que el proyecto avanza. Para ello el equipo dispone de dos herramientas:

- La documentación. En forma de diseño, consultoría, análisis o lo que sea deseable según el tipo de proyecto.

- El seguimiento periódico o de acuerdo con hitos. Para mostrar resultados, pedir aceptación, continuar con las siguientes fases, mostrar los problemas y proponer soluciones.

Para lograr esto la palabra proactivo es la clave. Sin un equipo proactivo, donde el jefe de proyecto constantemente tiene que tirar del carro, los resultados no son los esperados, y los problemas aparecen de forma inesperada.

Ser proactivo implica tener siempre presente el flujo de trabajo. Hacer lo que toca en cada momento, y alertar sobre desvíos. Solo cuando todo el mundo tiene el flujo en la cabeza, las personas trabajan de forma eficiente y aportan valor. No hay nada más deprimente que una reunión de seguimiento donde nadie tiene nada que decir, y siempre habla el jefe del proyecto. Esto debería ser un motivo de alarma. O el equipo no conoce el flujo, o no está de acuerdo con el flujo, el proyecto o la tarea, o no sabe trabajar en equipo, o no está motivado, por ejemplo.

Participación proactiva de los usuarios clave

Los usuarios clave no desaparecen durante la construcción del producto que luego ellos explotarán. Es justo al contrario. Los usuarios clave deben colaborar en la validación de las entregas parciales que se le entreguen, proponer soluciones a los problemas que aparezcan, ser conscientes de la evolución del proyecto, y alertar sobre gestiones del cambio que aparecen en el negocio, y que pueden impactar sobre el resultado del proyecto que se está construyendo.

Hay momentos en que el usuario clave es imprescindible, por ejemplo en la aceptación de nuevos incrementos del producto. Obviamente no es lo mismo participar y aceptar productos a pequeñas dosis, que aceptar al final el producto completo. Esta es la principal diferencia y la finalidad de los marcos de trabajo ágiles frente a métodos tradicionales.

Es posible que algunas organizaciones prefieran un enfoque en cascada para huir de un seguimiento y evaluación continuados; por el tiempo, dedicación y asunción de responsabilidad que representa. Esto es un grave error, y suelen ser organizaciones donde los proyectos necesitan grandes esfuerzos en la documentación del alcance, los requerimientos y la solución técnica. La documentación en este escenario se convierte en una herramienta de contratación interna. Más enfocada a cubrir responsabilidades, que a ser una herramienta útil para el equipo del proyecto.

Los momentos

El seguimiento de un flujo implica una serie de acciones o momentos en que algunas o todas las partes se ven implicadas y necesitan colaborar. Es imprescindible que esto sea así, sobre todo en escenarios de construcción iterativa.

Los proyectos deben subdividirse en partes asequibles para el equipo, y con suficiente valor para el área destinataria, para poder ser utilizado mientras se construye el resto del producto. Es en este escenario cuando se necesita la colaboración de todos los implicados para llevar a cabo las tareas siguientes:

- Definir y priorizar las piezas funcionales, historias de usuario, módulos funcionales, o como sea que organizamos una subdivisión del proyecto.

- Validar el alcance de cada parte.

- Hacer seguimiento de la ejecución de cada parte. Crear y validar el diseño que permite su construcción y, posteriormente, validar el resultado en una prueba real.

- Presentar la pieza construida en el área destinataria, y facilitar su uso por parte de los usuarios, en el entorno de explotación de la organización.

¿Qué hemos visto en esta sección?

- Para trabajar en equipo se necesitan herramientas y método.

- Los flujos de gobierno deben ser realistas y asumibles.

- Los flujos deben ser lo suficientemente flexibles para acomodar las visiones, estilos de gestión y marcos de trabajo que sean de uso habitual en la organización, y las necesidades particulares del proyecto.

- La normativa de gestión y ejecución no son el fin del proyecto. Son la herramienta de coordinación del proyecto.

- Los jefes de proyecto tienen la responsabilidad de conocer y hacer conocer los marcos y los flujos de trabajo.

- Una buena práctica en la gestión del proyecto es situar los riesgos como pieza central de la gestión.

- Es imprescindible el uso de plantillas, guías de uso y estándares documentales para conseguir un nivel documental de calidad aceptable para todas las partes del proyecto.

- Fabricar la documentación del proyecto tiene una parte mecánica y otra que depende de nuestra habilidad para plasmar la información necesaria, y resaltar lo verdaderamente útil.

- Los constructores y los proveedores deben conocer el flujo y utilizarlo de forma proactiva.

- El seguimiento de un flujo implica una serie de acciones o momentos en que algunas o todas las partes se ven implicadas y necesitan colaborar.

4. Focalizarse en la mejora continua y la gestión del cambio

Esta es una versión de libre distribución. Si te gusta lo que has leído hasta el momento puedes adquirir la versión completa en la tienda de Amazon. Tanto en versión Kindle como en papel:

5. La organización necesita establecer una gestión de programa

Esta es una versión de libre distribución. Si te gusta lo que has leído hasta el momento puedes adquirir la versión completa en la tienda de Amazon. Tanto en versión Kindle como en papel:

6. Establecer un canal constante para evaluar la satisfacción

Esta es una versión de libre distribución. Si te gusta lo que has leído hasta el momento puedes adquirir la versión completa en la tienda de Amazon. Tanto en versión Kindle como en papel:

Parte 2: Las acciones para fomentar el cambio

Todo lo que hemos visto en las secciones anteriores es una reflexión sobre las áreas en las que deberíamos focalizar, para fomentar un cambio en la visión de los proyectos en las organizaciones. Todo esto tiene poco valor si no somos capaces de hacer propuestas prácticas que nos sirvan para articular estos cambios. En esta parte realizamos algunas propuestas concretas sobre los factores vistos en la parte anterior.

En este capítulo intentamos dar las herramientas, o proponer acciones para:

Fuente: Change management: the human side of sustainable design (2013)[2]

- Empoderar a los miembros del equipo del proyecto (incluidos los usuarios) para que actúen como un organismo autónomo, autoorganizado, disciplinado, transparente, flexible, comprometido y fiable.

- Proponer las herramientas y métodos sobre los que asentar un marco de trabajo que sea conocido, comprendido y aceptado por todas las partes; y que ponga el foco en la construcción de producto de valor para la organización.

- Crear el escenario de trabajo en el que la mejora continua y la satisfacción sean el objetivo organizativo superior del proyecto.

- Por último, reflexionar sobre cómo los equipos de gestión de programa y PMO pueden ayudar en la gestión, la evaluación de necesidades, la mejora continua y la satisfacción.

1 y 2. Empoderar e los miembros del equipo

Para que los diferentes miembros del equipo asuman su responsabilidad, y trabajen de forma coordinada entre sí, hay que proporcionar básicamente cuatro pilares:

- Un espacio de trabajo que facilite la agilidad.

- Una estructura de relaciones, que responda a quién es responsable de qué, o quién hace qué.

- Un flujo de trabajo, que ayude al equipo a llevar a cabo sus tareas en el proyecto.

- Unos momentos o hitos, en el que el equipo se coordina, muestra los avances, resuelve problemas, etc.

La agilidad como herramienta de empoderamiento

Para aplicar agilidad en procesos complejos, donde intervienen a menudo un gran número de personas, es necesario ser conscientes de que las operaciones de gestión (el management) es demasiado importante para dejarlo solo en manos de gestores. Debemos transmitir la idea de que la gestión también es una tarea de equipo, y que el jefe del proyecto focaliza sus esfuerzos en crear el clima necesario para el fomento de la gestión eficiente y la creatividad, (cuida un jardín).

Esto no significa que el jefe del proyecto deje de tener la responsabilidad en la gestión y en el patrocinio de ciertas decisiones. Se trata de encontrar un clima de trabajo en el que el equipo es el auténtico protagonista sobre el cómo se hacen las cosas en su interno, y aquí el jefe del proyecto es un miembro más en el equipo.

El fomento de la creatividad es el principal motor de cambio de las personas. En cualquier proceso de cambio, los aspectos emocionales acostumbran a tener un predominio clave a la hora de iniciar un cambio (75%), por encima de aspectos estrictamente racionales (25%).

Fuente: Torben Rick[3]

Cambiar la forma de hacer de las personas no necesariamente es agilismo. El método taylorista[4] es el método más habitual i obviamente no lo es, cómo tampoco es el más eficiente en muchos casos. Una forma habitual de aplicar falsamente agilismo es llevando a cabo pequeños cambios que no alteren la jerarquía de la organización (usualmente taylorista). Es lo que es conoce cómo Cargo Cult[5].

Cargo Cult

Durante la II Guerra Mundial, en algunas islas del Pacífico, el gobierno de EE.UU. instaló pistas de aterrizaje provisionales, a fin de crear una vía de comunicación rápida para el abastecimiento de las tropas destinadas en la zona, y que luchaban contra el ejército japonés.

Las tribus de aquellas islas en general habían tenido poco contacto con las culturas occidentales y su tecnología. Ver aviones aterrizar en su isla era una experiencia mágica desde su punto de vista.

Font: Science-Based medicine (2016) Cargo Cult Psychology[6]

Los aviones llevaban material, que a menudo también era compartido con las tribus. Se generó la relación psicológica en que los aviones eran seres celestiales a los que había que adorar para mantener la vía de aprovisionamiento.

Una vez finalizada la II Guerra Mundial, algunas tribus simularon las pistas de aterrizaje, los edificios, e incluso los aviones, con materiales de la zona a fin de crear una ilusión de que "nada había cambiado", y poder seguir con el culto a estos dioses.

Las principales barreras en la adopción del agilismo son diversas, pero se pueden destacar:

- Resistencia general al cambio en la organización.

- Posibilidades reales de hacer efectivo un cambio cultural en la organización.

- Aplicar conceptos ágiles en un sistema organizativo anti-ágil[7], por causas tecnológicas, por el cumplimiento de normativa o burocracia externa, o de la misma organización, o por el sistema de relaciones entre departamentos y personas de la organización.

¿Que es una organización anti-ágil?

Una organización anti-ágil es aquella en la que sus elementos de coordinación interna y productivos se articulan en torno a dos elementos característicos: burocracia y jerarquía. De forma que, con el fin de llevar a cabo cualquier acción prevista, esta es evaluada a través de un proceso formal o informal que la pauta y la delimita (burocracia), y da respuesta a intereses de grupos que coordinan su idoneidad, alcance y temporalidad (jerarquía). Con la existencia de un núcleo que centraliza las decisiones, y que extiende su poder a toda la organización (Taylorismo).

Este tipo de organización (parte izquierda del gráfico siguiente) son vistos como una máquina; capaz de hacer un número concreto de acciones, y de una forma determinada, que además tenderá siempre a ser la más eficiente posible. Para alcanzar este máximo de eficiencia, muestra una tendencia en especializarse por secciones (o nichos). Los nichos actúan como engranajes independientes que tienen visión solo de una parte de la cadena de valor de la empresa, y donde se establecen vías estrictas de contacto con otros engranajes.

Cuando este tipo de organizaciones son sorprendidas con cambios tecnológicos, humanos, organizativos, políticos, presupuestarios, y un largo etc. que ponen en peligro su status quo actual, necesitan adaptarse[8]. La adaptación ante cambios y nuevas necesidades en una organización-máquina es posible, pero es lenta y a menudo desemboca en adaptaciones parciales que no cubren completamente lo que las forzó a cambiar.

Una organización ágil es aquella en la que los engranajes tienen todos ellos (o gran parte) una visión completa de la cadena de valor de la organización. Este tipo de organizaciones (parte derecha del gráfico anterior) tienen capacidad de decisión y son autoorganizadas. El centro de la organización no es visto como un centro de poder, sino como una guía en la dirección. La capacidad de adaptación de estas organizaciones viene determinada por su flexibilidad interna y externa. Los diferentes núcleos (o células) operativos pueden crecer, disminuir y alterar su organización interna y especialización. Pueden aparecer nuevas células para cubrir nuevas necesidades y adaptarse a los cambios, sean los que sean.

La agilidad como herramienta de empoderamiento[9]

El jefe de proyectos tiene, entre su repositorio de responsabilidades y objetivos, los siguientes retos con el equipo:

- Empoderar a las personas de forma individual, de forma que sean conscientes de su papel y de su valía en el equipo.

- De resultas de lo anterior, el jefe de proyecto tiene la misión de desarrollar competencias en el equipo y en las personas.

- Crear un ambiente de trabajo que facilite la toma de decisiones por el mismo equipo. El equipo no es un grupo de técnicos sin capacidad decisoria. Son profesionales autoorganizados que deciden cómo hacer el trabajo y cuando hacerlo.

- Identificar limitaciones. Hacer que el equipo sea consciente y encontrar soluciones.

- Escalar correctamente la estructura de la empresa, de forma que todas las visiones e intereses que impactan sobre el proyecto tengan cabida y voz en el equipo, y puedan colaborar.

- Mejora continua, como parte transversal de todo el proceso de ejecución del proyecto, pero que va más allá del resultado, ya que incluye a las personas del equipo, a los destinatarios del producto y al proceso de gestión.

Definición de la estructura de relaciones

Una estructura de relaciones documentada es un esfuerzo para explicar de forma gráfica las relaciones entre los diversos miembros del equipo, focalizadas en la asunción de responsabilidades.

El concepto de auditoría:

Los miembros de un equipo son eficientes cuando todos ellos juegan un rol principal por encima de cualquier otro rol: La colaboración[10]. Un equipo que colabora es un equipo eficiente. Este concepto es antagónico a otro concepto muy de moda en los últimos años: La auditoría.

Auditoría corresponde a "las acciones de verificar que un determinado hecho o circunstancia ocurre de acuerdo a lo planificado. En el ámbito de las organizaciones, una auditoría corresponde a la verificación operacional o administrativa para la validación del cumplimiento de las normativas jurídicas, políticas o normativas de la empresa respecto a la operación sujeta a auditoría"[11].

Uno de los aspectos más relevantes que diferencian un equipo ágil de un equipo tradicional o predictivo hace referencia a la colaboración y transparencia. En escenarios de trabajo basados en auditoría no se da la transparencia ni se crea el clima de colaboración necesario para aplicar la agilidad.

Un equipo sometido a auditoría significa que cuenta con miembros donde su única misión es dar OK o NOK a una acción previamente realizada. No ayudan, no colaboran, simplemente declaran si el trabajo realizado es adecuado a sus baremos. Pueden o no hacer públicos estos baremos, pero extrañamente los negociarán con el equipo.

Esto no es un equipo. Es una visión muy tradicionalista y jerárquica de la gestión basada en puntos de control que, si bien pueden tener una razón de ser, no aseguran la comprensión de las reglas del juego por parte del equipo. Las auditorías son generadoras de conflicto.

A continuación, mostramos una propuesta de estructura de relaciones, con todos los grupos y personas que intervienen en un proyecto:

En este gráfico vemos las personas que forman parte de un equipo de proyecto, que ya hemos descrito a lo largo de este libro. Con la intención de mostrar gráficamente y de una forma muy visible las relaciones que se establecen entre ellos, a continuación, las explicaremos de manera breve:

El jefe de proyecto es quien, en última instancia, tiene la responsabilidad principal de asegurar el contacto continuado de todos los miembros del equipo, lo cual quiere decir, concretamente:

- Asegurar que todos los miembros asumen sus responsabilidades.

- Asegurar que el equipo entiende el marco de trabajo y que lo sigue. Esto incluye principalmente el ciclo de vida, las metas de la gestión y la ejecución del proyecto, y la calidad.

- Asegurar que el equipo comprende la necesidad de pautar la ejecución, priorizar las tareas y seguir un plan consensuado.

- Asegurar que se cumplen los baremos de calidad que el equipo ha determinado para el proyecto.

El grupo de seguimiento evalúa el seguimiento del proyecto, en función a la información que el equipo, y principalmente el jefe de proyecto le traslada. Toma decisiones y ayuda a la priorización de los objetivos, y la resolución de los problemas y riesgos que sean de su competencia.

Idealmente, los miembros del grupo de seguimiento deben ver reflejados todos los intereses del proyecto y de la organización. Así pues, deben verse cubiertas las visiones tecnológicas, pero también la visión del negocio y de los constructores y proveedores.

La PMO es el órgano que apoya al equipo de proyecto para que se cumplan los requerimientos de calidad tanto en lo referente al producto del proyecto, como para el mismo proceso. Su vinculación con el proyecto no debe confundirse con una auditoría. Son parte del equipo y tienen tareas y responsabilidades asignadas. Por tanto, colaboran con el equipo en el aseguramiento de la calidad del proyecto.

El usuario clave es una figura primordial en el equipo; y tiene un nivel de participación en el que va más allá de ser un facilitador estático de información del negocio. Ayuda al equipo a priorizar los objetivos. Ayuda a definir la profundidad (el detalle) de los objetivos del proyecto y de su alcance. Ayuda a resolver los problemas, y en preverlos, identificarlos y mitigarlos. Por encima de todo ayuda a validar que el resultado del proyecto cumple las expectativas de calidad de forma iterativa e incremental.

Los facilitadores se constituyen como un puente en la comunicación entre los usuarios clave y el equipo del proyecto. Los facilitadores tienen sentido cuando la información de negocio necesaria para la ejecución del proyecto es o muy compleja, o muy dispersa. Si no es así, no debería haber ningún inconveniente en que tecnólogos y usuarios entren en contacto directo. Muchas organizaciones han llegado a la conclusión de que tecnólogos y usuarios nunca podrán entenderse. Es una visión típica de los años 90 que actualmente aún perdura.

Los jefes de proyecto proveedores son los responsables de la operativa de la construcción, implantación y/o adquisición por parte de los constructores asignados al proyecto. Tienen un papel muy parecido al jefe del Proyecto general, pero su ámbito de responsabilidad se centra en su equipo de construcción. A menudo el equipo de construcción se encuentra en las instalaciones del proveedor, y es poco conocido y accesible para el equipo del proyecto (lo cual usualmente es un grave error). El jefe de proyecto proveedor hace de pasarela entre los desarrolladores y el resto del equipo.

Los Colaboradores son aquellos que dentro del equipo desarrollan una tarea concreta, posiblemente aislada y/o especializada, pero igualmente necesaria para el proyecto. En el ámbito de un proyecto, todas las tareas necesarias deben ser cubiertas o bien lideradas por un miembro del equipo. Los colaboradores a menudo tienen una participación en forma de encargo para la resolución de una tarea del proyecto y después desaparecen, pero mientras llevan a cabo la tarea asignada son parte del equipo del proyecto.

¿Y quién es el Product Owner?

En Scrum, el propietario del producto es una única persona para el proyecto y producto, que tiene libertad para tomar decisiones sobre qué se hace y cuando, y su misión principal es asegurar que el equipo de proyecto entiende el objetivo y las funcionalidades del producto del proyecto.

Scrum.org, en su guía oficial (The Scrum Guide) define el papel del Product Owner de la forma siguiente:

“El propietario del producto (Product Owner) es el responsable de maximizar el valor del producto del trabajo del equipo de desarrollo (Development Team). Cómo se lleva a cabo puede variar ampliamente entre diferentes organizaciones, equipos Scrum e individuos.

El propietario del producto es la única persona responsable de gestionar la pila del producto (product backlog). La gestión de la pila del producto incluye:

- Expresar claramente los elementos de la pila del producto.

- Ordenar los elementos en la pila del producto para alcanzar los objetivos y las misiones de la mejor manera posible.

- Optimizar el valor del trabajo que realiza el equipo de desarrollo; que la pila del producto sea visible, transparente, clara para todo el mundo y que muestre lo que el equipo trabajará a continuación.

- Asegurar que el equipo de desarrollo entiende los elementos de la pila del producto al nivel necesario. El propietario del producto podría hacer el trabajo anterior o delegarlo en el equipo de desarrollo. Por otra parte, en ambos casos el propietario del producto sigue siendo el responsable de este trabajo.

- El propietario del producto es una única persona, no un comité. El propietario del producto podría representar los deseos de un comité en la pila del producto, pero aquellos que quieran cambiar la prioridad de un elemento de la pila deben hacerlo a través del propietario del producto.

Para que el propietario del producto pueda hacer correctamente su trabajo, toda la organización debe respetar sus decisiones. Las decisiones del propietario del producto se reflejan en el contenido y en la priorización de la pila del producto. Nadie puede pedir al equipo de desarrollo que trabaje en un conjunto diferente de requerimientos.”

Los momentos que acotan el proyecto: El inicio y el cierre del proyecto

De todos los hitos de gobierno de un proyecto, dos son especialmente importantes para el proyecto y los miembros del equipo:

- El inicio de proyecto, o Kickoff.

- El cierre de proyecto, o finalización.

Inicio del proyecto

El inicio de proyecto es una acción que permite arrancar el proyecto, y que culmina con la celebración de una sesión de kickoff, en la que todos los miembros del proyecto, y las personas impactadas o interesadas se reúnen y exponen todos los aspectos clave, con el objetivo de obtener un consenso que permita el inicio de la ejecución del proyecto.

Antes de la sesión de kickoff, el jefe de proyecto ha de realizar un trabajo ingente de preparación que se conoce cómo procedimiento de Inicio del proyecto i que veremos a continuación.

De forma resumida, el proceso de inicio de proyecto tiene como objetivo principal definir en detalle los objetivos, el alcance, y la relación de los miembros del equipo de proyecto, y sus responsabilidades. De hecho, muchos proyectos fracasan por[12][13]:

- Falta de acuerdo sobre su alcance.

- Carencia de una visión clara de los objetivos y beneficios que se obtienen con el producto del proyecto.

- Identificación errónea del impacto del producto de proyecto en el departamento destinatario; o en otros departamentos.

- Selección errónea de los miembros del equipo del proyecto.

- No identificación, o identificación errónea de las responsabilidades de los miembros del equipo del proyecto.

- No identificación, o identificación errónea de los principales riesgos del proyecto.

- No proporcionar el detalle suficiente de planes de mitigación de estos riesgos.

Para alcanzar un relato que sea aceptado por todas las partes en una sesión de inicio de proyecto, es necesario antes iniciar un proceso de definición con los usuarios clave, con los proveedores y con otras áreas afectadas; y negociar con ellos una visión clara y consensuada del proyecto y del producto resultante para determinar:

- Los objetivos.

- El alcance.

- Los riesgos.

- La planificación inicial y deseada.

- La organización del equipo, roles y responsabilidades.

- Las claves de éxito.

Una vez hecho esto, la sesión de kickoff se convierte en una coreografía de final controlado que tiene como único objetivo explicitar este consenso entre todas las partes.

El Cierre

El problema fundamental para determinar el momento del cierre de un proyecto reside n cuando podemos declarar la finalización del mismo: ¿Cuándo el producto del proyecto entra en producción? ¿Cuándo los usuarios clave dan su visto bueno? Cuando el/los proveedores finalizan su contrato?

Podría parecer que alguna de estas situaciones sería clave para determinar el momento del cierre, pero quien puede determinar el momento de cierre de un proyecto es sólo el equipo del proyecto, y lo hace de manera ordenada, consensuada y documentada. Un proyecto finaliza únicamente en dos escenarios posibles:

- El equipo del proyecto formaliza la cancelación del proyecto.

- El equipo del proyecto formaliza la finalización del proyecto.

En ambos casos es necesario exponer la situación final del proyecto y del producto del proyecto, Las acciones de continuidad, garantía y mantenimiento que se desprenden, y la valoración respecto a la satisfacción del proceso, del producto y respecto a las lecciones aprendidas.

Los principales hitos en la gestión de un proyecto

A modo de resumen, los principales hitos o momentos en un proyecto pueden resumirse en el siguiente diagrama:

Inicio de proyecto

Este hito ya se ha introducido en la sección anterior, pero aquí lo desarrollaremos completamente. El inicio del proyecto es un procedimiento que tiene cómo objetivo asentar las bases del gobierno y la ejecución del proyecto. Para conseguir esto es necesario establecer una serie de premisas del proyecto que podemos resumir en la lista siguiente:

- Conocimiento y aceptación por todas las partes del propósito del proyecto.

- Determinar los objetivos que persigue cumplir con el producto del proyecto.

- Consensuar una planificación, un marco presupuestario y una disponibilidad de recursos materiales y humanos.

- Cerrar un modelo organizativo para el proyecto, con roles y responsabilidades claras.

- Conocer los riesgos o impedimentos para la construcción del producto del proyecto, o que la generación de este producto puede causar.

Para determinar el detalle de todos estos aspectos se trabaja con todos los implicados siguiendo el flujo de trabajo siguiente:

1. Preparatoria

En esta fase el Jefe de proyecto que recepciona realiza una serie de tareas destinadas a abrir los sistemas de gestión y documentales del proyecto

- Construye una 1ª versión borrador del kickoff.

- Prepara las estructuras de gestión y de trabajo para el equipo (repositorios documentales, herramientas de ticketing, wikis, listas de riesgos, lista de requerimientos).

- Construye una primera planificación (documento PLN) con los aspectos que ya se conocen, de forma previa a iniciar las conversaciones con proveedores, usuarios clave y facilitadores, para organizar el kickoff.

2. Pre-kickoff

Esta fase consiste en una o varias sesiones con los principales interesados del proyecto (de negocio y proveedores) con el objetivo de documentar de forma completa el kickoff, de forma que incluyan todos los aspectos importantes necesarios para la ejecución del proyecto. Las principales entidades que se trabajan en estas sesiones son:

- Se consensuan y documentan los acuerdos para el Consenso Interno del Proyecto (CIP) con las diferentes partes que colaboran en la ejecución. Se relacionan los acuerdos con cada grupo de interesados para el gobierno del proyecto.

- Se consensuan los elementos de Coordinación del Proyecto (COP). Se relacionan los elementos de coordinación, roles, responsabilidades, comunicación y gestión del cambio.

- Se consensua con negocio y proveedores los riesgos que pueden afectar al proyecto (RIN). Se determinan responsables y líneas de actuación para la mitigación de estos riesgos.

- Se cierra una Planificación del proyecto (PLN), al menos en una versión inicial que permita las primeras iteraciones del proyecto.

3. Sesión de kickoff

El kickoff se configura como una sesión presencial donde todos los interesados en el proyecto ya han trabajado los acuerdos que se presentarán allí. Basado en una presentación de kickoff cuyo contenido veremos en la sección “Parte 3. Documentos y plantillas del proyecto”.

4. Post-kickoff

En la fase de post-kickoff se rubrica el acuerdo con la distribución de un acta, que incluye todos los acuerdos presentados en la sesión. Este punto da el pistoletazo de salida a la conformación oficial del equipo de proyecto; con la disponibilidad de todos los miembros del equipo; y al inicio de las tareas de ejecución.

Cierre de proyecto

Ya hemos comentado anteriormente que un proyecto finaliza cuando los miembros del equipo determinan que se han alcanzado los objetivos establecidos al inicio; o bien cuando decide abortar por causas justificadas.

Al igual que al inicio del proyecto, la finalización requiere la consecución de una serie de actividades que tienen como objetivo el cierre ordenado del proyecto, el aseguramiento de la explotación del producto del proyecto, la evaluación de la satisfacción de todos los implicados, y la evaluación de los beneficios obtenidos por el producto del proyecto.

1. Documentos de continuidad

El proyecto no termina cuando el producto se encuentra en explotación, sino cuando se ven cumplidos todos los requerimientos documentales e informativos necesarios para la explotación, el mantenimiento y el conocimiento de los usuarios:

- Manuales de usuario y plan de formación.

- Documentos de paso a operaciones.

- Documentos de paso al servicio de mantenimiento.

- Acuerdos y activación del servicio de mantenimiento, licenciamiento, evolutivo, adaptativo y correctivo.

2. Reunión de cierre

La reunión de cierre, al igual que en el inicio del proyecto, tiene como objetivo que todas las partes muestren un acuerdo sobre los objetivos cumplidos en el proyecto, las vías de evolución posibles, las lecciones aprendidas, la valoración en función de los objetivos cumplidos y la satisfacción, los acuerdos respecto a la garantía del producto del proyecto y los canales de mantenimiento. La reunión requiere el trabajo previo y conjunto de un documento de cierre, que será memoria para futuras acciones.

3. Reunión de lecciones aprendidas

Junto con la reunión de cierre, o bien en reunión aparte, el equipo reflexiona sobre la satisfacción tanto desde la perspectiva del producto logrado, como del proceso de coordinación del proyecto.

En esta reflexión el equipo documenta una serie de lecciones aprendidas que pueden servir para cambiar aspectos del proceso en futuros proyectos. También se determina la forma en que se evaluará la satisfacción de todas las partes involucradas. Se consensua el contenido de encuestas y/o entrevistas que tendrán lugar en diferentes momentos posteriores a la puesta en productivo del producto del proyecto.

4. Evaluación de beneficios y satisfacción

Esta actividad se ejecuta una vez finalizado el proyecto, y consiste en una evaluación de los resultados de encuestas y entrevistas de satisfacción, con el que actualizará el archivo de lecciones aprendidas, o levantará las alarmas o iniciativas que considere útiles en función de los resultados. Esto puede incluir acciones de evolución o adaptación del producto del proyecto, cambios sobre el gobierno del proyecto, y/o cambios sobre las normas de calidad.

Las reuniones

Las reuniones son momentos de coincidencia del equipo en el día a día de su trabajo en el proyecto. Este flujo de gobierno propone tres grandes reuniones: la de planificación de ciclo, la de seguimiento, y la de resultados y aceptación.

- Reunión de planificación de ciclo

La planificación (PLN) no es una acción única que se lleva a cabo al inicio de un proyecto. Esta concepción de la planificación como acción única inicial es una forma ineficiente de afrontar el cambio inevitable en las organizaciones actuales.

Se necesita más agilidad en la planificación; y proporcionar un método de trabajo que facilite una planificación dinámica basada en ciclos iterativos de construcción de valor para la organización. Pero es importante tener claros y cerrados el alcance y los objetivos que persigue el producto del proyecto. El dinamismo en la planificación no puede significar incluir o quitar arbitrariamente aspectos funcionales, operativos o tecnológicos considerados críticos.

Si planteamos la planificación como un elemento vivo que aparece de forma iterativa como meta en cada ciclo del proyecto, entonces nos veremos abocados a plantear la construcción de todos los documentos de ingeniería necesarios para el proyecto (diseño funcional, técnico, desarrollo, testing, etc.) también de forma iterativa e incremental. E incluso plantearemos las acciones de puesta en productivo y plan de formación de la misma manera. Esto facilita enormemente la tarea de evaluación continua y aceptación por parte de los usuarios clave y las áreas usuarias a las que va destinado el producto.

La planificación iterativa tiene una contrapartida importante: Hay que ser muy cuidadoso a la hora de mantener la coherencia de una planificación focalizada en ciclos, respecto al compromiso global en el desempeño de un alcance, unos objetivos, un presupuesto y un calendario. Esto requiere de un esfuerzo para que el equipo mantenga constantemente una visión global del proyecto. Esto es extensible a todos los elementos documentales y de ingeniería necesarios para la ejecución del proyecto. Todos los elementos que se construyen incrementalmente requieren de un esfuerzo adicional para mantener la coherencia global.

El documento que articula la planificación es el documento de Planificación (PLN), en el que quedan definidos el calendario, la forma en que se evalúa la calidad, la forma en que se comunicará y se organizará el proyecto, y la relación de riesgos y planes de mitigación.

- Reunión de seguimiento

No se ha de entender la reunión de seguimiento como el órgano de gobierno interno de proyecto. El equipo de proyecto no hace reuniones de seguimiento programadas en calendario. Se coordina cada día, y evalúa los resultados internos, o trata los problemas cada día.

La reunión de seguimiento es una acción que está por encima de la operativa diaria del proyecto, y que tiene como objetivo informar a los órganos de seguimiento, sobre las acciones realizadas hasta la fecha. Estas reuniones pueden ser planificadas, o tener lugar a demanda (cuando aparece un hito clave, o un problema que no se puede resolver en el interno del equipo).

El documento que articula la reunión de seguimiento es el Informe de Seguimiento (IFS). Se conforma como acta de reunión donde se expresa la situación general del proyecto, la situación de los riesgos, y las principales decisiones tomadas. Los informes de seguimiento son conocidos por todo el equipo del proyecto y determinan su priorización a alto nivel. El equipo es autoorganizado, pero no completamente autónomo. El órgano de seguimiento tiene la potestad de marcar la priorización de los grandes elementos funcionales, pero no la forma o el orden en que se realizan las tareas en el interno del equipo, ya que tenemos que respetar la premisa de que el equipo es autoorganizado.

- Reunión de resultados y aceptación

La reunión de resultados es la pieza que nos ayuda a determinar hasta qué punto somos de ágiles en la ejecución del proyecto. Un proyecto con un número elevado de sesiones de presentación de resultados y aceptación implica un flujo de trabajo focalizado en la obtención iterativa de producto de valor. Es decir, en la construcción iterativa e incremental del producto del proyecto, que es explotado por el usuario desde el primer ciclo.

Esta orientación tiene ventajas significativas en cuanto a la eficiencia y flexibilidad en el trabajo y en los resultados (Agile State Survey mayo 2019[14]). El 61% de mejora en el logro de los objetivos de calidad. 22% de mejora en la identificación de riesgos. 48% de mejora en la reducción de los riesgos. 46% de mejora en la satisfacción del usuario final. Son algunos de los valores constatados en la mejora general de procesos iterativos de entrega continuo de valor.

La presentación de resultados y aceptación articula directamente a través del producto creado, y de cómo este resuelve los objetivos planteados para el ciclo en curso. Sin documentos de presentación. Directamente con el producto. En la presentación de resultados también se busca activamente una acción práctica de aceptación por parte de los usuarios clave. La aceptación implica obligatoriamente la aceptación del incremento de producto proporcionado, y el inicio del ciclo siguiente.

3. Estandarizar las herramientas y los flujos de gobierno del proyecto

Esta es una versión de libre distribución. Si te gusta lo que has leído hasta el momento puedes adquirir la versión completa en la tienda de Amazon. Tanto en versión Kindle como en papel:

4. Focalizarse en la mejora continua y la gestión del cambio

Esta es una versión de libre distribución. Si te gusta lo que has leído hasta el momento puedes adquirir la versión completa en la tienda de Amazon. Tanto en versión Kindle como en papel:

5. Establecer una gestión de programa

Esta es una versión de libre distribución. Si te gusta lo que has leído hasta el momento puedes adquirir la versión completa en la tienda de Amazon. Tanto en versión Kindle como en papel:

6. Establecer un canal constante para evaluar la satisfacción

Esta es una versión de libre distribución. Si te gusta lo que has leído hasta el momento puedes adquirir la versión completa en la tienda de Amazon. Tanto en versión Kindle como en papel:

Parte 3: Documentos y plantillas del proyecto

Los documentos del proyecto deben servir para mostrar únicamente la información que es necesaria en cada momento. Con una orientación de ingeniería (problema/solución) y no narrativa. Lo que debe primar es la utilidad hacia los destinatarios del documento, y no contar una historia. Una plantilla pautada es un documento que presenta el contenido y la forma en que se debe cumplimentar, y se dan las pautas sobre cómo ha de exponerse esta información.

En las páginas siguientes mostraremos una ficha técnica para cada uno de los documentos que se proponen en los flujos de gobierno del proyecto, visto en secciones anteriores. En cada ficha, además del nombre del documento mostraremos la siguiente información:

- Descripción: Para que aplica el documento, o a qué pretende dar respuesta.

- Ámbito: Flujo (gestión o ejecución) sobre el que preferentemente tiene sentido el documento.

- Objetivos: Motivación del documento. Para qué está pensado y cuál es su justificación en la gestión del proyecto.

- Responsabilidad principal: Quién es el principal responsable del documento. La persona o personas responsables serán las que deben velar por la disponibilidad de la plantilla, hacerla llegar a las personas que trabajarán sobre el documento, velar por la integridad del contenido, distribuirla allí donde el documento sea necesario, y repositarla para su salvaguarda.

- Temporalidad: En qué momentos del flujo de gobierno se crea el documento, se actualiza con nueva información, o se cierra.

Los diferentes documentos que describiremos a continuación aparecen en diferentes momentos del flujo de gobierno del proyecto, identificando en el momento en que se crea o aparece por primera vez; en qué momentos se actualiza con información nueva o se revisa el contenido; y en qué momento el documento se cierra. Las leyendas para indicar esto al diagrama anterior son:

- C - Crea: El documento se crea.

- A - Actualizar: El documento actualiza.

- T - Cerrar: El documento se cierra.

Puedes consultar el índice de contenidos de cada documento en la sección “Plantillas y contenidos de los principales documentos de proyecto”.

Documentos para la gestión del proyecto

En esta sección se expone la familia de documentos que se utilizan para articular la gestión del proyecto:

Documentos de inicio de proyecto

Los documentos de inicio del proyecto se articulan a partir del kickoff, que corresponde al acta que documenta los acuerdos, organización, planificación y todos los aspectos clave que gobernarán el proyecto que acaba de empezar. Como complementos al documento de kickoff encontramos:

- CIP: Consenso Interno de Proyecto.

- COP: Coordinación del proyecto.

El primero corresponde a la documentación de los acuerdos de gestión y ejecución del proyecto por parte de los diferentes grupos que participan. Cualquier acuerdo no estándar entre la dirección del proyecto y alguno de estos grupos se documenta aquí.

El segundo corresponde a la definición de la coordinación para el proyecto. Organigrama, matriz de roles y responsabilidades, definición de los comités de seguimiento, y cualquier otra información necesaria para la coordinación.

Kickoff - Acta de constitución / Kickoff del proyecto

Descripción

Contrato de inicio del proyecto.

Temporalidad

Se prepara en la fase de inicio de gestión del proyecto, en la fase de preparatoria, se amplía información en caso necesario a la reunión de kickoff y obligatoriamente se cierra la fase de post-kickoff, requiriendo aceptación.

Objetivos

Documento que explica los aspectos críticos del proyecto, y que se conforma como contrato entre todas las partes.

Ámbito

Ciclo de gestión.

Responsabilidad principal

Jefe de proyecto, proveedor y usuarios clave.

Esta es una versión de libre distribución. Si te gusta lo que has leído hasta el momento puedes adquirir la versión completa en la tienda de Amazon. Tanto en versión Kindle como en papel:

Anexos

Anexo 1: Glosario de documentos

Kickoff - Contrato de inicio del proyecto

- Kickoff - Acta de constitución / Kickoff del proyecto

- CIP - Consenso Interno de Proyecto

- COP - Coordinación de Proyecto

Documentos de propuesta de solución, planificación, riesgos y calidad

- PLN - Planificación de proyecto

- RIN - Registro de Incidencias y de Riesgos

- REQ - Catálogo de Requerimientos

Diseño y definición

- AVI - Análisis de viabilidad

- DFU - Diseño Funcional

- DTE - Diseño Técnico

Testing y pruebas

- ETP - Especificación Técnica de Pruebas

- PPR - Plan de pruebas documentado

Manuales

- MEX - Manual de Explotación

- MDE - Manual de Despliegue

- MIA - Manual de Instalación y Administración

- MOP - Manual de Operatoria

- MUS - Manual de Usuario

Plan de Desarrollo

- PdD - Plan de desarrollo

Seguimiento

- ACT - Acta (google docs | plantilla Confluence | word)

- ARD - Archivo diario: Lista de lecciones aprendidas y eventos ocurridos durante la ejecución del proyecto (google sheets | excel)

- IFS - Informe de Seguimiento (google docs | plantilla Confluence | word)

Métricas de Aseguramiento de la Calidad

- MAQ - Métricas y aseguramiento de la calidad

Cierre de proyecto

- CPR - Cierre de Proyecto

Anexo 2: Plantillas y contenidos de los principales documentos de proyecto

Esta es una versión de libre distribución. Si te gusta lo que has leído hasta el momento puedes adquirir la versión completa en la tienda de Amazon. Tanto en versión Kindle como en papel:

Anexo 3: Catálogo de riesgos usuales

Riesgos en la puesta en marcha del proyecto

- No se define correctamente la necesidad

- No se determina el proveedor / fabricante de la solución

- No se negocia correctamente los términos del contrato

- No se negocia correctamente la propiedad intelectual

- El proveedor no proporciona los servicios de apoyo necesarios para poder llevar a cabo el proyecto

- No se define correctamente los servicios post-proyecto

- El proveedor / Fabricante entra tarde en el proyecto

- Conflicto entre responsables del proyecto del proveedor y de la organización

- El proveedor no recoge correctamente los requerimientos iniciales en detalle

Riesgos sobre el presupuesto

- El presupuesto no está correctamente dimensionado, u olvida coberturas o servicios necesarios para llevar a cabo el proyecto

- El presupuesto no es factible atendiendo a los recursos, alcance o tiempo necesarios

- La gestión del cambio provoca cambios graves sobre el presupuesto

- Retrasos en la disponibilidad presupuestaria ponen en riesgo el proyecto

Riesgos sobre el alcance y los objetivos

- El alcance no está alineado con las necesidades de los destinatarios o con su línea de negocio

- El alcance no se ha podido definir completamente

- Cambios continuos en el alcance hacen perder el rumbo marcado inicialmente

- Aparecen enunciados en el alcance que no se reflejan los requerimientos

- Las estimaciones sobre el alcance o requerimientos no son exactas

- Dependencias de enunciados del alcance o requerimientos no están contempladas

- La relación de enunciados del alcance no incluye tareas que son necesarias para el proyecto (y por tanto no se valoran)

- Los requerimientos no están alineados con el alcance

- Los requerimientos no están definidos en detalle, son incompletos o causan confusión

Riesgos sobre el equipo del proyecto

- El equipo está infradimensionado

- El equipo necesita una curva de aprendizaje no prevista

- El equipo no dispone de una figura experta

- El equipo es inexperto

- El equipo tiene sobrecarga de trabajo y no puede atender el proyecto de forma adecuada

- El equipo tiene ideas inadecuadas o negativas hacia el proyecto

- El equipo no está motivado

- El equipo no se informa de forma correcta a los responsables funcionales y los usuarios clave

- No se sigue la metodología de gestión y ejecución del proyecto

- No se llevan a cabo las acciones de control de forma adecuada

Riesgos sobre aspectos técnicos, arquitectura, infraestructura

- La disponibilidad de arquitectura no es correcta, no es flexible o no es de suficiente calidad

- La arquitectura definida no es factible

- El diseño de la solución no es factible

- El diseño de la solución no está documentado

- El diseño de la solución no es flexible a los cambios

- El diseño de la solución no se adapta a las necesidades de negocio planteadas

- El diseño no se adapta a las posibilidades técnicas, de arquitectura o infraestructura

- Un componente tecnológico necesario no cumple los requerimientos de calidad

- Un componente tecnológico no es adecuado respecto a escalabilidad, buenas prácticas o los estándares definidos en la organización

- Un componente tecnológico presenta vulnerabilidades de seguridad

- Un componente tecnológico compromete otros productos o componentes

- La integración con otro producto o componente no es posible

- La integración con otro producto o componente no es correcta

Riesgos sobre terceras partes o comunicaciones

- Falta de apoyo directivo

- Falta de una figura clara de responsabilidad

- El jefe de proyecto no es vista como figura de autoridad

- Falta de entendimiento entre dirección y usuarios

- Persona clave en la dirección abandona proyecto u organización

- La falta de personas clave o presupuesto ponen el riesgo el proyecto

- El equipo de proyecto entiende mal los requerimientos

- Exceso de comunicaciones sin valor

- Falta de comunicación y de procedimiento comunicativo

- Usuarios / Destinatarios mal informados

- Usuarios particulares tienen especial impacto y no han sido informados

- La falta de formación pone en riesgo la viabilidad del producto

- Hay retraso en la toma de decisiones que impactan negativamente en el proyecto

- Las decisiones no son claras o no son comprendidas por algunos de los actores del proyecto

- Las decisiones no resuelven la problemática planteada

- Problemas organizativos o de disponibilidad de recursos clave ponen en riesgo el proyecto

- Una reestructuración organizacional pone en riesgo el proyecto

- Una regulación externa pone en riesgo el proyecto

- Un cambio repentino en el negocio pone en riesgo el proyecto

- Un cambio técnico repentino pone en riesgo el proyecto

Riesgos sobre el destinatario del producto

- Usuarios clave no participan en el proyecto

- Usuarios clave no tienen una visión clara del alcance

- Usuarios clave están sobre ocupados

- Usuarios clave no proporcionan una correcta visión de negocio o apoyo al proyecto

- Usuario clave conflictivo

- Usuario clave mal informado sobre la situación del proyecto en cuanto a coste, calendario, alcance, requerimientos o cambios

- El usuario rechaza el proyecto

- Los usuarios no aceptan la maqueta del producto del proyecto

- La solución no resuelve completamente la problemática expuesta por los usuarios

- La IG es de baja calidad, o plantea problemas de accesibilidad

- La solución provoca un descenso en la productividad del área usuaria

Riesgos sobre la gestión del cambio

- Los cambios aumentan en exceso la complejidad del proyecto, el coste o los recursos

- Usuarios clave no aceptan algunos cambios

- Los cambios no se priorizan de forma correcta

- Los cambios no se documentan adecuadamente

- Los cambios entran en conflicto con el alcance o con los requerimientos

- Percepción que el proyecto fracasa debido a los cambios

- La gestión del cambio no está soportada sobre un sistema de gestión

- La gestión del cambio no está soportada sobre un flujo de trabajo determinado

- No se tiene una visión a modo salpicadero de la situación de los cambios

Anexo 4. Referencias

Esta es una versión de libre distribución. Si te gusta lo que has leído hasta el momento puedes adquirir la versión completa en la tienda de Amazon. Tanto en versión Kindle como en papel:

Anotacions

[←1]

Blade Runner. Live in fear, 2009 (https://www.youtube.com/watch?v=KS0Rc45tj60)

[←2]

Font: Change management: the human side of sustainable design (2013)

(https://murgildu.wordpress.com/2013/04/08/change-management-the-human-side-of-sustainable-design/)

[←3]

Torben Rick (https://www.torbenrick.eu/blog/change-management/emotional-and-rational-case-for-organizational-change/)

[←4]

Scientific management (https://en.wikipedia.org/wiki/Scientific_management)

[←5]

Cult cargo: https://ca.wikipedia.org/wiki/Cultes_Cargo

[←6]

Science-Based medicine (2016) Cargo Cult Psychology  (https://sciencebasedmedicine.org/cargo-cult-psychology/)

[←7]

Los cinco rasgos de las organizaciones ágiles, por McKinsey (https://simonjosepulido.wordpress.com/2018/03/07/los-cinco-rasgos-de-las-organizaciones-agiles-por-mckinsey/)

[←8]

Agility: It rhymes with stability (https://www.mckinsey.com/business-functions/organization/our-insights/agility-it-rhymes-with-stability)

[←9]

Barriers to agile adoption, (https://www.leadingagile.com/2013/11/barriers-to-agile-adoption/)

[←10]

Cooperar o colaborar: ¿dos términos enfrentados? (http://blogs1.uoc.es/racev/recursos-racev/bases-teoricas-para-la-practica/cooperar-o-colaborar-dos-terminos-enfrentados/)

[←11]

Auditoría, (https://es.wikipedia.org/wiki/Auditor%C3%ADa#Tipos_de_auditor%C3%ADa)

[←12]

Hamed Taherdoost, Abolfazl Kesharvarzsaleh (2015), Critical factors that LEad to projects success/failure in a global marketplace

https://core.ac.uk/download/pdf/82098133.pdf

[←13]

Ashley Coolman (2015) Top 5 Reasons for Project Failure and How to Avert Disaster (https://www.wrike.com/blog/top-reasons-for-project-failure/)

[←14]

State of agile: https://www.stateofagile.com/#ufh-c-473508-state-of-agile-report

Table of Contents

Introducción y agradecimientos

Parte 1: Las claves

1. Empoderar a los usuarios clave

¿Qué significa empoderar?

Factor 1: Responsabilidad del usuario en el proyecto

Factor 2: Conocimiento del negocio

Factor 3: Clima de las comunicaciones

Factor 4: Hablar el mismo idioma (jerga del negocio)

2. Empoderar el equipo del proyecto

Empoderar a un desconocido

Factor 1: ¿Qué entendemos por equipo?

Factor 2: El equipo del proyecto es más que la suma de un jefe de proyecto y unos constructores o proveedores

Factor 3: Todos los miembros del proyecto tienen tareas asignadas

Factor 4: Los facilitadores también formen parte del equipo del proyecto

Factor 5: Conocimiento suficiente del negocio

Factor 6: Responsabilidad del jefe de proyecto

Factor 7: Canales claros para rendir cuentas

Factor 8: El control de todos los aspectos de gestión

3. Estandarizar las herramientas y los flujos de gobierno del proyecto

Factor 1: Los flujos de gobierno son un marco de trabajo para el equipo

Factor 2: La normativa de gestión y ejecución no son la finalidad del proyecto, son la herramienta de coordinación

Factor 3: Flujo de gestión del proyecto

Factor 4: Flujo para la ejecución del proyecto

4. Focalizarse en la mejora continua y la gestión del cambio

5. La organización necesita establecer una gestión de programa

6. Establecer un canal constante para evaluar la satisfacción

Parte 2: Las acciones para fomentar el cambio

1 y 2. Empoderar e los miembros del equipo

La agilidad como herramienta de empoderamiento

Definición de la estructura de relaciones

Los momentos que acotan el proyecto: El inicio y el cierre del proyecto

Los principales hitos en la gestión de un proyecto

3. Estandarizar las herramientas y los flujos de gobierno del proyecto

4. Focalizarse en la mejora continua y la gestión del cambio

5. Establecer una gestión de programa

6. Establecer un canal constante para evaluar la satisfacción

Parte 3: Documentos y plantillas del proyecto

Documentos para la gestión del proyecto

Documentos de inicio de proyecto

Anexos

Anexo 1: Glosario de documentos

Anexo 2: Plantillas y contenidos de los principales documentos de proyecto

Anexo 3: Catálogo de riesgos usuales

Anexo 4. Referencias